4.3 Redis Replication

1. Why Redis Replication Is Needed

• Distributed System Replication

2. What Is Redis Replication?

• Copy data into multiple replicas and deploy them on other machines.
• Replication is the foundation of Redis high availability (Redis Cluster / Redis Sentinel).

2.1. Replication Topology

• One master and one slave: used for failover when the master fails.
  • 
• One master and multiple slaves: multiple slave nodes are used for read/write separation.
  • 
• Tree-shaped primary-replica topology: an intermediate layer reduces replication pressure on the master.
  • 

3. How to Enable Redis Replication

• master
  • Configuration

daemonize yes
bind 127.0.0.1
port 6379
dir "/home/user/software/redis/redis0/data"
logfile "/home/user/software/redis/redis0/log/6379.log"

- Start
    - `redis0/bin/redis-server redis0/conf/redis.conf`

• slave
  • Configuration

daemonize yes
bind 127.0.0.1
port 6380
dir "/home/user/software/redis/redis00/data"
logfile "/home/user/software/redis/redis00/log/6380.log"
slaveof 127.0.0.1 6379
slave-read-only yes

- Start
    - `redis00/bin/redis-server redis00/conf/redis.conf`
- Check status: `redis00/bin/redis-cli -p 6380 info replication`

4. Redis Replication Principles

4.1. Primary-Replica Replication

Distributed System Replication Architecture: Primary-Replica Replication

4.1.1. Leader Election

4.1.1.1. Election Method

The master is manually specified at startup.

4.1.1.2. Split-Brain Problem

With manual switching, there is no automatic-election split-brain problem.

4.1.2. Data Synchronization

4.1.2.1. Synchronization Process

• Full replication: the master starts a background process to generate an RDB file and sends it to the slave; the slave restores the data.
  • The slave sends psync -1.
  • The master replies with FULLRESYNC.
  • The slave saves the master information.
  • The master executes bgsave to save the RDB locally.
  • The master sends the RDB to the slave.
  • The master continues responding to client read/write commands and writes changes into a buffer.
  • The slave clears its data.
  • The slave loads the RDB.
• 

4.1.2.2. Synchronization Mode

Asynchronous.

4.1.2.3. Synchronization Log

Logical log.

4.1.3. Request Processing

4.1.3.1. Read Requests

Read requests can be handled by the master or a slave. With read/write separation, they are generally handled by slaves, so more nodes can increase read throughput.

4.1.3.2. Write Requests

Write requests must be handled by the master and are then replicated to slaves.

4.1.4. Failure Handling

4.1.4.1. Failure Detection

The master and slaves use heartbeats to stay alive.

4.1.4.2. Failure Recovery

4.1.4.2.1. slave failure

• Reconnecting after a slave failure triggers incremental replication.
• Incremental replication: each command written by the master is placed in a buffer and then sent to the slave, which replays the command.
  • The slave disconnects.
  • The master keeps writing into the buffer.
  • The slave reconnects to the master.
  • The slave sends psync.
  • The master sends buffered data to the slave.
• 

4.1.4.2.2. master failure

• Manually promote a slave to master and notify the other slaves of the master change.

5. Problems with Redis Replication

• Failure recovery is complicated.
  • Once the master fails, we need to manually promote a slave to master, modify code or connection configuration, reconnect, and so on.
• Write capacity is limited by a single machine.
  • Usually the master handles writes while slaves only handle reads.

6. References

• Replication – Redis